CycloneDDS 多参与者合并：SquashParticipants 配置

单个进程创建多个 DCPS 参与者时，每个参与者都会在 DDSI 层独立参与发现与活跃性声明，后台消息量随之成倍上涨——单进程在网络上看起来像一个拥有大量参与者的大系统。CycloneDDS 提供了两个配置项来合并进程内的多个参与者，本文整理自官方文档 Combining multiple participants（11.0.0），适合遇到发现流量过大或想优化多参与者进程的读者。

问题：进程内多参与者的后台流量

上层框架在单个进程里创建多个参与者并不少见。每个参与者都要发送自己的活跃性断言（liveliness assertion）并维护各自的发现端点，参与者的数量直接决定这些周期性后台消息的规模。当进程内参与者很多时，这部分开销会变得可观。

Internal/SquashParticipants

把这个内部选项设为 true，可以把进程内的多个 DCPS 域参与者合并为单个 DDSI 域参与者对外呈现——对外相当于只存在一个参与者，它拥有该进程创建的所有端点。

收益是后台消息量显著减少：活跃性断言只需要按一个参与者发送，而不是每个参与者各发一份。

代价同样明确：

• 工具无法再显示真实的系统拓扑结构——所有端点都挂在同一个参与者名下
• 与域参与者相关的活跃性监控会受影响；对 AUTOMATIC_LIVELINESS（默认的自动活跃性）没有问题，手动活跃性相关的监控语义会失真

还有一个容易踩的细节：保留下来的唯一参与者，其 QoS 属性取自进程中创建的第一个参与者。如果其他参与者设置了各自的用户数据（UserData），这些数据在远程节点上均不可见。

替代方案：Internal/BuiltinEndpointSet = minimal

如果不想合并参与者，可以把 Internal/BuiltinEndpointSet 设为 minimal：此时只有第一个参与者拥有内置端点的 Writer，并在所有实体上发布数据，同样能减少一部分内置通道的流量。

注意此设置与其他 DDS 实现并非完全兼容：它意味着本方可能会收到尚未被发现的参与者的端点发现数据。跨厂商互操作的场景要谨慎评估。

要点

• 进程内多参与者 → 活跃性断言等后台消息成倍增长；Internal/SquashParticipants=true 合并呈现为一个参与者，代价是拓扑工具失真、参与者级活跃性监控受影响（自动活跃性除外）
• 合并后保留参与者的 QoS 取自第一个创建的参与者，其余参与者的 UserData 对远端不可见
• 不合并的替代项是 Internal/BuiltinEndpointSet=minimal，但有跨实现兼容性风险
• 两者都是 Internal/ 前缀的内部选项，升级 CycloneDDS 版本时值得复查行为是否变化